The new unit tests cover basic string-literal preservation, but they don’t cover the failure mode where apostrophes appear inside SQL comments (e.g., -- don't ...) and interfere with the string-splitting state machine. Adding a test case with a comment containing a single quote followed by a schema-qualified identifier would help prevent regressions once comment-handling is fixed.

stripSchemaQualificationsPreservingStrings treats every single quote as the start/end of a SQL string literal, but it doesn’t account for quotes appearing inside SQL comments (e.g., -- don't ...). A single apostrophe in a -- or /* ... */ comment can flip inString and cause the rest of the SQL text to be treated as “string”, preventing schema qualification stripping for subsequent statements (potentially creating objects in the real schema instead of the temp schema). Consider extending the splitter to recognize and skip over line/block comments (and only toggle inString when not inside a comment).

stripSchemaQualificationsFromText compiles multiple regexes on every call. With the new string-literal splitting, it can now be invoked many times per SQL statement (one per non-string segment), which can significantly increase CPU/time on large schemas. Consider compiling the regexes once per schemaName per stripSchemaQualifications invocation (or caching by schemaName) and reusing them across segments.

E'...' backslash-escaped quote not handled

The escape-string syntax E'it\'s public.test' uses \' (backslash + single quote) to embed a quote rather than '' (doubling). The current parser only recognises the '' form:

if i+1 < len(text) && text[i+1] == '\'' {
    i += 2 // skip ''
}

With E'content\'' suffix, the \ is consumed as an ordinary character; then when ' (the real escaped quote) is reached and the following char is ' (the string closer), the code treats both as a '' pair and skips them — leaving inString = true beyond the true end of the string. Any schema identifiers after the closing quote will therefore be treated as string content and not stripped.

The failure mode is a false-negative (missed stripping) rather than a false-positive (corruption), so it is safe but subtly incorrect. A doc comment or a test case capturing this limitation would make the boundary explicit.

stripSchemaQualificationsPreservingStrings toggles inString on every single quote without accounting for SQL comments (-- ... / /* ... */). A single apostrophe inside a comment (e.g., -- don't strip) can cause the rest of the file to be treated as an unterminated string, skipping schema stripping for subsequent statements and potentially executing schema-qualified DDL against the real schema instead of the temp schema. Consider extending the scanner to recognize and skip comment regions (or strip comments before scanning), and add a unit test that includes an apostrophe in a comment before a public.-qualified reference.

The unquoted-schema regexes (re3/re4) can match the target schema name as a suffix of a longer identifier because the only prefix check is (?:^|[^"]). For short schema names (e.g., schemaName=s), a reference like sales.table can be partially matched and rewritten incorrectly (e.g., corrupting sales.table to saletable). Consider requiring a non-identifier boundary before the schema name (start or a char not in [a-zA-Z0-9_$"]) and preserving the delimiter via a capture group rather than consuming an arbitrary preceding character.

stripSchemaQualificationsFromText’s re3/re4 replacement assumes the first byte of match is the delimiter to preserve. When the regex matches at the beginning of the string (because of the ^ alternative), match[0] is actually the first letter of the schema name, producing wrong output (e.g., public.t -> pt). The regex/replacement should distinguish “start-of-string” vs “preceded by delimiter” (typically by capturing the prefix as a group and reusing it in the replacement).

The comment claims the E'...' limitation is “safe”, but the current parser can still strip schema qualifiers inside an E-string literal, changing object definitions and potentially reintroducing destructive false-positive diffs (the same failure mode as #371, just for E-strings). Either handle E-strings (treat backslash-escaped quotes as non-terminating) or clarify in the docs/tests that this case can change semantics and is not guaranteed safe.

stripSchemaQualificationsPreservingStrings does not handle Postgres escape-string literals (E'...') with backslash-escaped quotes. With input like E'it\'s public.test' FROM public.t;, the scanner will treat the \' as a string terminator, causing the later ' to be treated as a new (unterminated) string. This can produce invalid SQL and/or skip stripping after the string. Consider detecting E-strings and treating a quote as escaped when preceded by an odd number of backslashes (or avoiding splitting on ' when preceded by E and then using an E-string-aware scan).

The “E-string with backslash-escaped quote” case assumes the output remains valid SQL (and expects a specific transformation), but the current splitter will treat \' as a string terminator and can end up producing an unterminated string literal / skipping subsequent stripping. Once E-string handling is fixed in stripSchemaQualificationsPreservingStrings, update this expected value to reflect the corrected behavior (and consider asserting validity/round-trip expectations for E-strings explicitly).